Adding tabbing navigation and accessibility to map #270

ahmadayubi · 2021-01-29T14:38:12Z

2021-01-29.09-28-12_Trim.mp4

Allow features to be tab navigable and add crosshair to map when query layer exists + map is tab focused

Closes #268 also closes #260

Edit:
Now adds navigation bypass

2021-02-05.10-39-17.mp4

Closes #280

Malvoz · 2021-02-01T00:49:05Z

The features are indistinguishable to someone relying on a screen reader as they don't have an accessible name. <path tabindex="0"> is announced as graphic in Chrome (blank in Firefox):

Keyboard.Interaction.Test.-.Google.Chrome.2021-02-01.01-37-.mp4

Malvoz · 2021-02-01T01:03:56Z

When using the NVDA screen reader it's not possible to open popups by pressing Enter or Space when a feature has focus. This works on other elements such as controls, supposedly because they're standard interactive elements.

prushforth · 2021-02-01T01:32:28Z

The features are indistinguishable to someone relying on a screen reader as they don't have an accessible name.

I see that the <path> element supports a child <title> element that provides an accessible name. If we can come up with a convention for providing a similar accessible name for <feature>, we could generate the <path><title> from it.

When using the NVDA screen reader it's not possible to open popups by pressing Enter or Space when a feature has focus.

That's a problem. Open to suggestions to achieve this. Maybe we should open the popup when the feature receives focus, and dismiss it on blur?

ahmadayubi · 2021-02-01T14:16:39Z

Maybe we should open the popup when the feature receives focus, and dismiss it on blur?

I think opening a pop up on focus alone might be an annoying interaction to have with a webpage. Adding a title element seems like a good solution based off: https://www.w3.org/TR/SVG11/struct.html#DescriptionAndTitleElements .

prushforth · 2021-02-01T16:24:47Z

I think opening a pop up on focus alone might be an annoying interaction to have with a webpage.

I'm not saying you're wrong, just want to think about this a bit here.

When a user clicks or touches a feature when the map isn't in "focus mode", the feature either pops up a balloon or if there's a query available it pops up a balloon after receiving the response. Presumably (I am presuming) tab-to-focus a feature is the equivalent operation to touching it for a sighted person, so the user wants to hear the properties if they're using a screen reader.

Given the extremely generic properties model that <feature> has, I wonder if we should add a <title> element child of <properties> as a special case for accessible names purposes similar to svg. In the polyfill we can map that to <title> or what have you. I'll open an issue on this latter discussion in the MapML and UCR document repos.

prushforth · 2021-02-01T16:28:29Z

I think in the short term, we could generate an accessible name on the element that has the value <path><title>feature</title></path>. I think if a feature isn't provided an accessible name in the future (even if we add <title>), we'll still have to generate something that screen readers can announce (they might not need a fake <title> if they ever come to support <feature>).

Malvoz · 2021-02-02T05:52:29Z

I think opening a pop up on focus alone might be an annoying interaction to have with a webpage.

I'm not saying you're wrong, just want to think about this a bit here.

When a user clicks or touches a feature when the map isn't in "focus mode", the feature either pops up a balloon or if there's a query available it pops up a balloon after receiving the response. Presumably (I am presuming) tab-to-focus a feature is the equivalent operation to touching it for a sighted person, so the user wants to hear the properties if they're using a screen reader.

Tab-to-focus is more of a discovery phase (perhaps tedious, depending on the amount of features), where e.g. <title> would provide the accessible name for discernibility (discernibility is also an issue present for regular focusable markers!). Touching is equivalent to pressing Enter or Space once an element has focus. I agree that popups shouldn't open on focus.

"focus mode" is a term to describe one of few modes in screen readers but I take it you're referring to when the reticle is visible? This mode currently has some usability issues:

The user doesn't necessarily know they can press Space to get details for features. aria-keyshortcuts may be useful here, but visual users would need this info on screen. Of course, if this was a standard behavior people would know this by heart.
Features that have other features stacked on top of them cannot be interacted with, I believe.
Particularly screen reader users:
- don't know which feature the reticle is on at any given moment (which feature is available to them). Although if features are in the tab order then they can reach them by sequentially navigating instead.
- don't know that they're actively panning (and in which direction) when pressing the arrow keys as there is no such feedback (but I suppose this is a stand-alone issue, which is also true in regards to zooming).

(Also popups aren't announced when opened. This is an issue with Leaflet popups in general, we're tracking the upstream issue in #247.)

Esri's a11y-map (yes I'm referring to them again! 😋) doesn't have these issues because each feature within the "scope" is:

Announced to the user via ARIA live regions when panned to.
Assigned a keyboard shortcut that can be pressed, to expand details.

pressing 1 reveals:

I think the a11y-map's interaction model is intuitive, it doesn't need to include features in the tab order (unlike regular documents).

ahmadayubi · 2021-02-02T14:17:39Z

a11y's querying is similar to Google's, and it works well when you have a discrete number of features. In mapml from what I can tell there can be a continuous number of queryable points on the map. There's querying a layer and querying a feature. Querying a layer is continuous but "querying" features is discrete. If you had to use the square model of a11y or google maps you would only show that conditionally as you still have the issue of continuous querying.

I guess you could introduce a new crosshair + square hybrid? Where numbers query a feature but space queries the center?

Malvoz · 2021-02-03T20:41:47Z

I'm getting a strange bug where the popup is misplaced when opening it by pressing Enter, only when using a screen reader (NVDA in this case):

Keyboard.Interaction.Test.-.Google.Chrome.2021-02-03.21-01-.mp4

Malvoz · 2021-02-03T21:33:03Z

src/mapml/layers/MapLayer.js

@@ -94,7 +94,7 @@ export var MapMLLayer = L.Layer.extend({
                if (properties) {
                  var c = document.createElement('div');
                  c.insertAdjacentHTML('afterbegin', properties.innerHTML);
-                  geometry.bindPopup(c, {autoPan:false});
+                  geometry.bindPopup(c, {autoPan:false, closeButton: false});


Why are close buttons not useful in feature's popups?

I think @shepazu mentioned they might be problematic, or it might have been me misinterpreting something...

It was suggested that it be removed, should it be added back?

I think having a close button is fine, with the following caveats:

the popup should not be a modal (that is, it shouldn't be a focus trap)

if possible, we shouldn't force screen reader users to "close" each feature popup to move on to another feature

This seems like somewhat competing experiences between voice-control and screen-reader users, in exposing the right amount of detail with the fewest possible number of forced interactions. My preference would be to have the popup not exposed to screen readers on focus, but only read the accessible name (the popup "title"), with notification of additional information (e.g. aria-expanded) to access the other popup details only on demand (at which point they might encounter the close button, but that's fine, because they chose to expand it). For voice-control users, I think having the popup on focus should be good, with scrolling for long details, and a close button.

Does this seem right to you, @Malvoz?

I think having a close button is fine, with the following caveats:

the popup should not be a modal (that is, it shouldn't be a focus trap)

The popups are non-modal, so focus traps are (mostly*) not an issue.

*when the popup for the last feature in the sequence is opened tabbing is currently trapped to some extent (shift + tab can be used to move back to the previous feature):

Keyboard.Interaction.Test.-.Google.Chrome.2021-02-08.11-06-.mp4

if possible, we shouldn't force screen reader users to "close" each feature popup to move on to another feature

Because focus (generally) isn't trapped inside popups users don't have to explicitly close popups before moving on to other features/focusable elements.

This seems like somewhat competing experiences between voice-control and screen-reader users, in exposing the right amount of detail with the fewest possible number of forced interactions.

I'm not super familiar with voice-control so I'm not sure about how there are competing experiences here. I do know that some people use voice-control to move their cursor around to interact with elements, in that case I think a close button could be appreciated if they just wanted to close a popup without opening a new one.

My preference would be to have the popup not exposed to screen readers on focus, but only read the accessible name (the popup "title"), with notification of additional information (e.g. aria-expanded) to access the other popup details only on demand (at which point they might encounter the close button, but that's fine, because they chose to expand it).

Yes I think we agreed that popups should not be opened (and thus exposed to ATs) when a feature recieves focus, and that each feature itself should be labelled for discernibility. (discussion from #270 (comment))

I agree that features that are interactive and have popups should expose the state of the popup using aria-expanded.

prushforth · 2021-02-03T21:39:20Z

I think the reticle / graticule could be about 2x as big and bold, personally. I find it easy to not notice. WDYT?

ahmadayubi · 2021-02-04T14:18:47Z

I'm getting a strange bug where the popup is misplaced when opening it by pressing Enter, only when using NVDA:

@Malvoz when I use it I don't even get a popup? I put a breaker on leaflet code responsible for creating the popup and it seems with NVDA running that code is never reached, Certain keyboard events might be getting hijacked?

I found this:

Source http://melmo.github.io/accessibility/code/dist/leaflet.html

ahmadayubi · 2021-02-04T14:40:09Z

I think the reticle / graticule could be about 2x as big and bold, personally. I find it easy to not notice. WDYT?

For reference this is what 2x would look like, that's not considering bolding either. It goes from being a map with a UI to being a UI with a map, if that makes sense, but you're right in that it might make seeing it easier. Pros and cons.

Currently its 36x36px, maybe making it 44x44px is appropriate so it's the same size as the buttons?

…Custom-Element into featureFocus

ahmadayubi added 6 commits January 27, 2021 10:03

Allow features to be focused

831e5fb

Adds crosshair, shows on keyboard movement

ba5078b

Shows crosshair on tab

1c75af6

Only run on moveend if there are queryable layers

8d82998

Revert listener change

9d9029e

Adds tests for keyboard interaction

97b811d

ahmadayubi marked this pull request as ready for review January 29, 2021 18:16

Merge branch 'master' into featureFocus

5812169

Merge branch 'master' into featureFocus

f7f1497

ahmadayubi and others added 2 commits February 2, 2021 09:25

Merge branch 'master' into featureFocus

64476e6

Remove close button from feature popup

f5911b0

ahmadayubi changed the title ~~Allow features to be tab navigable and add crosshair to map when query layer exists + map is tab focused~~ Adding tabbing navigation and accessibility to map Feb 2, 2021

ahmadayubi mentioned this pull request Feb 3, 2021

Feature tabbing bypass blocks #280

Closed

ahmadayubi and others added 3 commits February 3, 2021 11:31

Add bypass navigation

61a83d4

Query popup fix

edc2cf0

Merge branch 'master' into featureFocus

a8d82fd

Merge branch 'master' into featureFocus

525d68e

Malvoz reviewed Feb 3, 2021

View reviewed changes

Merge branch 'master' into featureFocus

2ed2749

ahmadayubi and others added 10 commits February 4, 2021 13:11

Add feature count, move controls to bottom

3147842

Merge branch 'featureFocus' of https://github.com/ahmadayubi/Web-Map-…

783d521

…Custom-Element into featureFocus

Test update to consider skip buttons

8bc75ce

Test update

69478aa

Adds next and previous focus buttons

7326fa1

Add tests for keyboard interaction

19aaf5e

Rename variables and add comments

d227589

Remove handlers on close

8b3b1ef

Merge branch 'master' into featureFocus

0f69555

Merge branch 'master' into featureFocus

a6c7f8d

prushforth merged commit 4f8ff65 into Maps4HTML:master Feb 10, 2021

prushforth mentioned this pull request Feb 12, 2021

Query handling keyboard access #291

Closed

Malvoz mentioned this pull request Feb 16, 2021

Test Popup Text Cycling with Screenreader #296

Open

This was referenced Feb 24, 2021

role="application" #274

Closed

Features should have accessible names for discernability #316

Closed

Malvoz mentioned this pull request Apr 14, 2021

Meaningful Pan & Zoom (and Feature navigation) #396

Open

Malvoz mentioned this pull request Apr 22, 2021

Popups are misplaced when using a screen reader #423

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Adding tabbing navigation and accessibility to map #270

Adding tabbing navigation and accessibility to map #270

ahmadayubi commented Jan 29, 2021 •

edited

Loading

Malvoz commented Feb 1, 2021

Malvoz commented Feb 1, 2021

prushforth commented Feb 1, 2021

ahmadayubi commented Feb 1, 2021

prushforth commented Feb 1, 2021

prushforth commented Feb 1, 2021

Malvoz commented Feb 2, 2021

ahmadayubi commented Feb 2, 2021

Malvoz commented Feb 3, 2021 •

edited

Loading

Malvoz Feb 3, 2021

prushforth Feb 3, 2021

ahmadayubi Feb 5, 2021

shepazu Feb 5, 2021

Malvoz Feb 8, 2021 •

edited

Loading

prushforth commented Feb 3, 2021

ahmadayubi commented Feb 4, 2021 •

edited

Loading

ahmadayubi commented Feb 4, 2021 •

edited

Loading

Adding tabbing navigation and accessibility to map #270

Adding tabbing navigation and accessibility to map #270

Conversation

ahmadayubi commented Jan 29, 2021 • edited Loading

Malvoz commented Feb 1, 2021

Malvoz commented Feb 1, 2021

prushforth commented Feb 1, 2021

ahmadayubi commented Feb 1, 2021

prushforth commented Feb 1, 2021

prushforth commented Feb 1, 2021

Malvoz commented Feb 2, 2021

ahmadayubi commented Feb 2, 2021

Malvoz commented Feb 3, 2021 • edited Loading

Malvoz Feb 3, 2021

Choose a reason for hiding this comment

prushforth Feb 3, 2021

Choose a reason for hiding this comment

ahmadayubi Feb 5, 2021

Choose a reason for hiding this comment

shepazu Feb 5, 2021

Choose a reason for hiding this comment

Malvoz Feb 8, 2021 • edited Loading

Choose a reason for hiding this comment

prushforth commented Feb 3, 2021

ahmadayubi commented Feb 4, 2021 • edited Loading

ahmadayubi commented Feb 4, 2021 • edited Loading

ahmadayubi commented Jan 29, 2021 •

edited

Loading

Malvoz commented Feb 3, 2021 •

edited

Loading

Malvoz Feb 8, 2021 •

edited

Loading

ahmadayubi commented Feb 4, 2021 •

edited

Loading

ahmadayubi commented Feb 4, 2021 •

edited

Loading